The present invention relates to a technique for executing processing in another information processing apparatus, or a program or an object that conducts its processing, in response to occurrence of a failure or a predetermined condition, or a request.
For conventional database management systems (or computer systems or information processing systems), there is a technique of placing a plurality of replications in a plurality of geographically distributed sites (computers or information processing apparatuses) by way of precaution against failures, i.e., the so-called disaster recovery technique. In the so-called disaster recovery technique, data of a certain site are stored in other geographically separated sites as replications. In the case where a failure is caused by a disaster or the like in a certain site, business is recovered in another site.
For database management systems (or computer systems or information processing systems, where database management systems are taken as an example), there are several methods as a technique of having such replications. Basically, a request is sent to a system that becomes principal when seen from clients, i.e., a primary system, and an information record called log is generated in the primary system, and used to recover the processing and as backup. In other words, this log record is sent from the primary system to a system called secondary system, and a host computer of the secondary system conducts the same modification processing as the primary system by referring to the log record and thereby modifies the state of the secondary system. Such a technique of implementing the replication by sending a log record generated in the primary system to the secondary system is disclosed in U.S. Pat. No. 5,640,561.
In a remote copy function (see U.S. Pat. No. 5,640,561) in a storage apparatus used when sending a log record or database data generated in a primary system to a secondary system, conventional data transfer methods are mainly divided broadly into the following two kinds.
(1) Synchronous Method
Upon a data write request from a host computer in a certain site (herein referred to as main site), a storage apparatus in the main site transfers pertinent data to a storage apparatus in another site (herein referred to as remote site). After arrival of a receipt report of pertinent data from the storage apparatus in the remote site, the storage apparatus in the main site reports writing completion to a host computer in the main site.
There is a merit that it is assured that data have arrived at the remote site when writing has been completed in the main site. On the other hand, there is a drawback that an increase in distance between sites or line delay increases the write response time in the main site and causes performance degradation.
(2) Asynchronous Method
When a data write request from a host computer in a main site has arrived, a storage apparatus in the main site reports writing completion to the host computer in the main site without waiting for completion of pertinent data transfer to a remote site.
As compared with the synchronous method, the possibility of performance degradation in the main site is reduced. In the case where a failure has occurred in the main site, there is a possibility that recent data are lost in the remote site and transactions are lost.
There are methods in which it is assured that the sequentiality of data writing in the main site coincides with that in the remote site as disclosed in U.S. Pat. No. 5,640,561, and methods in which it is not assured. For avoiding that the state in the middle of a transaction remains and consistency of a database cannot be assured, it is necessary to assure the sequentiality of data writing. The sequentiality assurance can be configured so as to be effective for a set of a plurality of disks. A technique for assuring the sequentiality for a set of a disk for log (journal) and a disk for DB is disclosed in U.S. Pat. No. 5,640,561.
In general, a database management system (DBMS) has a DB disk for storing data itself and a log disk for storing DB modification history information in a time series form. If a server in the main site (which is a computer or an information processing apparatus in the main site) is shut down, data on the DB disk assumes an incomplete modification state in some cases. At the time of restart of the DBMS, however, a consistent state is recovered on the basis of the DB modification history information on the log disk. (Such a technique is disclosed in Jim Gray and Andreas Reuter, “TRANSACTION PROCESSING: Concepts and Techniques,” published by Morgan Kaufmann Publishers, which is hereafter referred to as reference paper 1) In other words, at the time of server shut down, modification data of completed transactions are forced to the DB disk (rollforward), and modification data of transactions that have been incomplete at the time of server down are invalidated (rollback).
As a transfer method in the disaster recovery system, the following methods are known.
(a) Log Synchronous and DB Synchronous Method
The log and DB are transferred synchronously to the remote site. The same states of the log and DB as those in the main site are always present in the remote site. When a failure has occurred, recovery processing in the same situation as the restart in the main site can be implemented. In other words, modification contents of transactions that have been completed in the main site are not lost in the remote site. Since the log and DB are transferred synchronously, however, the performance in the main site is degraded as compared with the case where such a configuration is not adopted.
(b) Log Asynchronous and DB Asynchronous Method
The log and DB are transferred asynchronously to the remote site. In addition, the modification sequentiality in the remote site is guaranteed. Since the modification in the remote side is delayed, states of the log and DB assumed in the main site the delay time before are present in the remote site. By making the modification sequentiality of the log and DB assured, the consistent DB state assumed in the main site the delay time before can be recovered. Although the performance degradation in the main site is slight, modification contents of transactions that have been completed in the main site are sometimes lost in the remote site.